Course: Android App Development
Topic: Managing API Keys, Tokens, and Authentication Credentials
Course Link: Android App Development Course
Demo Link: Register for a Course Demo
Website: JustAcademy
Android applications commonly connect to REST APIs, backend servers, cloud platforms, payment services, and authentication providers. These services may require API keys, access tokens, refresh tokens, session cookies, or other authentication credentials.
Credentials help identify an application or user and determine which resources they can access. If credentials are exposed, attackers may be able to access protected information, misuse APIs, or perform unauthorized operations. Therefore, developers must understand how credentials work, where they should be stored, how they should be transmitted, and when they should be renewed or revoked.
This topic covers credential types, secure storage, HTTPS communication, authentication workflows, token expiration, refresh operations, logout, troubleshooting, and practical Android implementation examples.
An API key is a value used by an API provider to identify an application, project, or calling client. It may be used for usage tracking, quotas, billing, service restrictions, or access control.
For example, a weather application may request current weather information from a remote service. The provider may require an API key to identify the application making the request.
GET https://api.example.com/weather?city=Mumbai
X-API-Key: YOUR_API_KEYThe exact format depends on the API provider. Some services use a request header, while others specify a different authentication method. Follow the provider's official documentation.
Never assume that a value is secret simply because it is stored in a Kotlin file, XML resource, Gradle configuration, or an obfuscated APK. If the application needs a confidential server-side credential, keep it on a backend server instead of packaging it inside the Android application.
An authentication token is a credential used to represent an authenticated user, client, or authorization grant. A server or identity provider may issue tokens after a successful login or authorization process.
An access token allows an application to request protected resources. It is commonly sent in the HTTP Authorization header.
Authorization: Bearer ACCESS_TOKENAccess tokens should be treated as sensitive credentials. Anyone who obtains a usable token may be able to access resources permitted by that token until it expires or is revoked.
A refresh token is used to obtain a new access token when the current one expires, if the authentication provider supports token renewal. Refresh tokens are often longer-lived and must be protected carefully.
Refresh tokens should never be logged or exposed to unrelated services. Use token rotation and revocation when supported by the identity provider.
An ID token is used by OpenID Connect to communicate authentication information about a user to a client. It may contain claims such as the user's identifier and token expiration time.
An ID token is not automatically interchangeable with an access token. Each token should be used only for its intended purpose and validated according to the provider's requirements.
Some applications use session cookies instead of bearer tokens. After authentication, the server creates a session and the application sends the relevant cookie with subsequent requests. Session identifiers must also be treated as sensitive credentials.
| Credential | Purpose | Typical Use | Security Concern |
|---|---|---|---|
| API key | Identifies an application or project | Accessing an API with provider-defined restrictions | May be extracted from the APK |
| Access token | Authorizes access to protected resources | Sending authenticated API requests | May allow unauthorized access if stolen |
| Refresh token | Obtains a replacement access token | Maintaining a session without repeated login | Can provide extended access if compromised |
| ID token | Provides authentication claims | Identifying an authenticated user to a client | Must be validated and used for its intended purpose |
| Session cookie | Maintains a server-managed session | Authenticated web or API requests | Session theft may permit impersonation |
Hardcoding credentials means placing a secret directly in application source code.
// INSECURE EXAMPLE — do not use
const val API_SECRET = "real-secret-value"
const val USER_PASSWORD = "password123"Hardcoded values can accidentally be committed to source control or extracted from a compiled application. Keep confidential API secrets on a protected backend and use suitable restrictions for client-side keys.
Saving tokens in unprotected files or ordinary preferences may expose them if the device, application data, backup, or debugging environment is compromised. Choose storage based on credential sensitivity and the application's threat model.
Unencrypted HTTP traffic can expose credentials to interception. Use HTTPS for authentication and credential-bearing API requests. Never disable certificate validation to work around connection problems.
// INSECURE EXAMPLE — never log real credentials
Log.d("Auth", "Access token: $accessToken")Tokens and authorization headers may be captured in Logcat, debugging output, crash reports, or diagnostic tools. Log a generic status message instead.
Repeatedly refreshing an invalid token can create retry loops, unnecessary requests, and session failures. Implement controlled refresh logic and return the user to the login flow when renewal is no longer possible.
There is no single storage method that makes every credential completely secure on a user-controlled device. Select an approach based on the credential's value, the authentication provider, Android version requirements, and the application's security needs.
| Storage Method | Recommended Purpose | Limitation |
|---|---|---|
| Android Keystore | Creating and protecting cryptographic keys | It is not a general-purpose token database |
| Encrypted local storage | Storing sensitive application data encrypted with a protected key | Requires correct encryption and key management |
| DataStore or SharedPreferences | Storing ordinary application preferences | Plain storage is not appropriate for high-value credentials |
| Identity provider SDK | Managing supported login and token workflows | Requires correct provider configuration |
| Backend secret manager | Storing confidential server-side API keys and secrets | Requires secure backend access controls |
Android Keystore provides a system for creating and using cryptographic keys while limiting direct access to their key material. Depending on the device and configuration, keys may receive hardware-backed protection.
Developers can use Keystore-backed keys for encryption, decryption, or signing operations. Sensitive data can then be encrypted before it is written to local storage.
Important: Keystore does not automatically encrypt arbitrary token strings. The application must use a correct encryption and storage design or rely on an appropriate authentication SDK.
If a third-party service requires a confidential API key, the recommended architecture is for the Android application to call your backend, which then calls the third-party API using the server-side key.
Android Application
|
| HTTPS request
v
Your Backend Server
|
| Confidential key stays on server
v
Third-Party APIThe backend can validate the user, enforce permissions, apply rate limits, and protect the confidential credential.
Development, staging, and production environments should use separate configuration values. Gradle build configuration can help organize non-secret values such as base URLs.
// app/build.gradle.kts
android {
defaultConfig {
buildConfigField(
"String",
"API_BASE_URL",
"\"https://api.example.com\""
)
}
}This example defines a base URL, which is generally not confidential. Moving a private key into Gradle or BuildConfig does not make it secret if the value is packaged into the APK.
After login, an application may receive an access token and, depending on the provider, a refresh token. These credentials should not be stored in source code, unprotected files, analytics events, or diagnostic logs.
For production applications, prefer a reputable identity-provider SDK when available. If the application needs its own secure token-storage implementation, use a suitable encrypted-storage approach and protect its encryption key with Android Keystore.
interface TokenRepository {
suspend fun getAccessToken(): String?
suspend fun saveTokens(
accessToken: String,
refreshToken: String?
)
suspend fun clearTokens()
}This interface separates credential storage from the rest of the application. It does not itself encrypt anything; the implementation must provide the required protection and error handling.
Retrofit and OkHttp are commonly used in Android applications to communicate with REST APIs. A request interceptor can attach the current access token to requests sent to a trusted API.
class AuthHeaderInterceptor(
private val tokenProvider: () -> String?
) : okhttp3.Interceptor {
override fun intercept(
chain: okhttp3.Interceptor.Chain
): okhttp3.Response {
val original = chain.request()
val token = tokenProvider()
val requestBuilder = original.newBuilder()
if (!token.isNullOrBlank()) {
requestBuilder.header(
"Authorization",
"Bearer $token"
)
}
return chain.proceed(requestBuilder.build())
}
}This example assumes that tokenProvider can synchronously return the current access token. Configure the interceptor only for the intended API host. Never send a bearer token automatically to unrelated websites or third-party domains.
Access tokens usually have a limited lifetime. When a token expires or becomes invalid, a server may return HTTP 401 Unauthorized. The application should follow the API provider's documented behavior rather than assuming every 401 response requires a refresh.
suspend fun getUsableAccessToken(): String? {
val current = tokenRepository.getAccessToken()
if (current != null && !isKnownToBeExpired(current)) {
return current
}
// Placeholder: use the provider's documented refresh flow.
return authenticationService.refreshAccessToken()
}The functions in this example are illustrative and are not built-in Android APIs. The server remains responsible for validating tokens and enforcing authorization, even if the client checks expiration locally.
If several API requests fail simultaneously, each request may attempt to refresh the same token. This can cause unnecessary requests and may break authentication systems that rotate refresh tokens.
Recommended practices include:
OAuth 2.0 is an authorization framework. OpenID Connect adds an identity layer that supports user authentication. These standards are widely used by applications that need secure sign-in and access to protected APIs.
PKCE, or Proof Key for Code Exchange, helps protect the authorization-code exchange. It does not hide API keys inside an APK or replace secure token storage.
Credential leaks can occur through more than source code. Logcat output, crash reports, analytics events, screenshots, and diagnostic bundles may unintentionally expose sensitive information.
// Safer logging
Log.d("Authentication", "Token refresh completed")
// Never log the actual token or Authorization header.Logging out should clear the application's local authentication state. Where supported, the application should also revoke refresh tokens or terminate the server-side session.
Clearing a local token does not automatically invalidate a stolen copy. Server-side revocation and expiration policies are important parts of session security.
Use separate environments for development, testing, and production. This reduces the risk of test code or development credentials affecting real users and live services.
| Environment | Purpose | Security Practice |
|---|---|---|
| Development | Feature development and debugging | Use test accounts and restricted credentials |
| Staging | Pre-release testing | Restrict access and avoid real user data where possible |
| Production | Live users and services | Use strict access controls, monitoring, rotation, and secure secret management |
| Problem | Possible Cause | Recommended Solution |
|---|---|---|
| HTTP 401 Unauthorized | Missing, expired, invalid, or malformed token | Check the authentication flow and follow the provider's refresh or re-login rules |
| HTTP 403 Forbidden | Insufficient permissions or scopes | Check roles, scopes, account permissions, and API restrictions |
| API key fails in release builds | Incorrect environment or signing-certificate restrictions | Verify release configuration and provider restrictions |
| Token disappears after restart | Token stored only in memory or persistence failure | Review the intended session policy and secure storage implementation |
| Refresh requests keep failing | Refresh token expired, revoked, or rotated incorrectly | Review provider responses and require sign-in when necessary |
| Credentials appear in crash reports | Sensitive headers or exception data are captured | Redact credentials and review reporting configuration |
| API key exposed in APK | Confidential key packaged in the client | Rotate the key if needed, move confidential operations to a backend, and apply restrictions |
Build a simple Android application that allows users to sign in and view protected profile information. The application should demonstrate secure credential management and session handling.
com.example.secureauth
├── data
│ ├── AuthApi.kt
│ ├── AuthRepository.kt
│ └── SecureTokenStore.kt
├── network
│ ├── ApiClient.kt
│ └── AuthHeaderInterceptor.kt
├── ui
│ ├── LoginScreen.kt
│ └── ProfileScreen.kt
└── MainActivity.ktThis structure is illustrative. Adapt it to the libraries and architecture used in your application. Test credential storage, refresh coordination, and network authorization independently.
An API key is a value used by a service to identify an application or project and may be used for quotas, restrictions, or access control.
An access token is used to access protected resources. A refresh token can be exchanged for a new access token when the authentication provider supports that process.
Application packages can be inspected or reverse-engineered, so a hardcoded confidential key may be extracted and misused.
Android Keystore is a system for creating and using cryptographic keys with protections that can limit direct access to key material.
HTTPS encrypts communication in transit and helps protect credentials from interception when TLS is configured correctly.
It should follow the provider's documented renewal flow, refresh the token when appropriate, and require authentication again if renewal fails.
Logs and diagnostic systems may expose credentials, allowing unauthorized parties to use them.
PKCE is an OAuth extension that helps protect authorization-code exchanges for public clients, including native mobile applications.
No. Local deletion removes the application's copy but does not necessarily invalidate other copies. Server-side revocation or expiration may also be required.
They should generally be stored on a protected backend server or in a server-side secrets manager, not inside the Android application package.
Managing API keys, tokens, and authentication credentials is a fundamental part of secure Android development. Developers must understand the purpose of each credential, store sensitive values appropriately, transmit them securely, and handle expiration, renewal, and logout correctly.
By using established authentication libraries, keeping confidential secrets on the backend, protecting sensitive local data, restricting API keys, and enforcing server-side authorization, developers can build Android applications that communicate with APIs more safely and reliably.
Learn more through the JustAcademy Android App Development Course, register for a course demo, or visit the JustAcademy website.
